ソシャゲエンディング後のアプリの実装手法紹介　膨大なアセット、流動的なデータ保存を「シノアリスだったナニカ」はどう扱ったのか #CEDEC2024 #classmethod_game

こんにちは、ゲームソリューション部の入井です。
今回はCEDEC2024で聴講したセッション『ソシャゲエンディング後のアプリの実装手法紹介　膨大なアセット、流動的なデータ保存を「シノアリスだったナニカ」はどう扱ったのか』についてレポートします。

セッション概要

2024年1月15日に約6.5周年のサービス運用を終了したシノアリス。
メインストーリーを終了したユーザーから「シノアリスだったナニカ」にアプリ自体が変化し、
ユーザー自身がアプリ内でお墓に入る、というシノアリスらしいゲーム体験がユーザーからご好評をいただきました。
「シノアリスだったナニカ」ではアプリのAPIサーバー停止後でも、
メインストーリーやムービー、キャラクターズたちのアセットの閲覧や
運営中に所持していたプレイヤー自身の一部データなどを閲覧することができる上、
運用期間中にアプリを１度もプレイしていなかった方でもシノアリスのユーザーたちのお墓などを閲覧できる、という機能を実現しています。
本講演ではその機能をどのように実装したのか、というところを深掘りしてお話しします。

※CEDEC2024セッションページより引用

印象に残った点

『シノアリス』と『シノアリスだったナニカ』

シノアリスは、2017年にサービスを開始したスマートフォン向けのRPGで、いわゆるソーシャルゲームと呼ばれる運営型のゲームです。今年2024年1月にサービスが終了しましたが、その際に『シノアリスだったナニカ（以下、ナニカ）』という名前にアプリ名が変わり、現在でも各ストアからダウンロードできるようになっています。

『ナニカ』では、今までインターネットの利用が前提になっていたメインストーリーやミニゲーム等がオフラインで遊べるようになっています。その他にも、様々なユーザーが登録したプロフィールデータが閲覧できたり、エンディングまでプレイしたユーザー向けに自身のプレイ記録を閲覧できるアーカイブ機能が提供されています。

上記の仕様から、『ナニカ』はエンディングまでプレイしたユーザー向けのフルパッケージ版と、それ以外のユーザー向けの通常版の2種類があります。

『シノアリス』から『ナニカ』への移行は、サービス終了前から各ユーザーのプレイ状況に応じて個別に行われていく仕様でした。そのため、単に運営終了のタイミングでアプリを更新するだけで仕様を満たせず、『シノアリス』と『ナニカ』が不具合無く混在できるよう特殊な対応をする必要がありました。

インフラ構成とナニカの設定ファイル

各ユーザーの『シノアリス』と『ナニカ』の状態管理をハンドリングするため、現在のサービス運営状態を定義するための設定ファイルがクラウド上に作成されました。

サービス運営中の構成図は以下の通りで、AWSを中心にアプリサーバー等を利用しつつ、Google Clooudも組み合わせている形でした。

一方、サービス終了後はAWSとGoogle Cloud上の大部分のサービスは不要になるため利用を停止し、AWSのS3についてのみ各クライアントからアクセスできる形で残されました。これにより、S3内に保管された設定ファイル経由でクライアントアプリの挙動をハンドリングできるようにしています。

設定ファイルでは、現在のアプリの状態やバージョン情報、規約同意用ポップアップのテキストなど様々な情報が格納されており、クライアントは必要に応じてそれらの内容を参照して適切な処理を行います。

例えばアプリサーバーのAPIから取得したデータを画面描画する処理について、『シノアリス』と『ナニカ』の混在期間は『ナニカ』であっても従来通りAPIからデータを取得するが、サービス終了後はオフライン用の処理で表示する、というように現在のアプリの状態によって処理内容を分ける必要があります。このような場合は分岐判定のためにS3上の設定ファイルを参照することで、アプリにアップデートをかけなくても時期に応じた適切な処理を行えるといった設定ファイルの活用例の紹介がありました。

ナニカのアセット管理

ゲームアプリは様々なアセットを取り扱う関係上、アプリ容量がどうしても大きくなります。『シノアリス』や『ナニカ』も同様で、大小様々なデータがゲームで使われています。

これらのデータをアプリ自体に内包するとサイズが10GB以上となりAppStore/PlayStoreの上限を超えてしまうことから、『シノアリス』ではゲーム内で専用のアセット配信サーバーからダウンロードする形になっていました。

『ナニカ』への移行にあたっては、データの取捨選択をすることでアプリサイズを抑え、アプリサーバーと共にアセット配信サーバーも停止させる案もあったとのことですが、取捨選択自体に大きな工数がかかることや、『シノアリス』と『ナニカ』で表現内容に差が生まれてしまうことから、アセット配信サーバーは引き続き稼働を継続する方針になりました。

もちろん、その場合アセット配信サーバーの維持費が『ナニカ』移行後もかかり続けることになりますが、内包した場合のコストに追いつくまでに50年かかる程度の費用に抑えられているとのことでした。

DummyResponceによるユーザー固有データの表示

『ナニカ』でアプリが表示するデータの中には、プレイヤー自身のプレイ記録や所属ギルド情報など各ユーザーで内容が異なるものがあります。

これらのデータは、『シノアリス』運用中はサーバーから取得する形でアプリ内に表示していましたが、『ナニカ』移行後はサーバーが停止されることから別の手段を取る必要が発生しました。アセットと同様にS3から配信する手段もありますが、各ユーザーのプライベートな情報であることや、都度通信によるコストが発生してしまうことから採用されませんでした。

そこで考えられたのがDummyResponseという仕組みでした。これは、アプリサーバーが稼働中は通常通りAPI経由でデータを取得し、サーバー停止後にAPIからレスポンスが得られなかった場合は端末上にあらかじめ保存しておいたデータを取得する、というロジックが入ったAPIリクエストプログラムです。

このDummyResponseの仕組みを取り入れたことで、個々のAPIリクエストコール部分のプログラムを回収しなくても、サービス終了運用前後でデータ取得先を切り替えることが可能になりました。

感想

運営型ゲームはサービス終了後にゲームを遊べなくなってしまうという課題について、最近はオフライン版を開発するという形で対応するタイトルが増えてきました。
しかし、オフライン化はそれ自体にかなりの開発工数がかかりますし、『シノアリス』のようにオフライン化への移行自体により良いゲーム体験を盛り込むことを考える場合、このセッションで紹介されたような様々な工夫が必要となります。
大変ではありますが、このような施策は運営型ゲームだからできる唯一無二なものであり、その分ユーザーに対してもゲームタイトルに強烈な印象を残すとこができそうだと思いました。